\documentclass[11pt,a4paper,spanish,openright,twoside]{report}
\usepackage[spanish,activeacute]{babel}			
\usepackage[utf8]{inputenc}
\usepackage{supertabular}
\usepackage{multirow}
\usepackage{graphicx}
\usepackage[top=2.5cm, bottom=2.25cm, outer=2.75cm, inner=2.75cm, heightrounded, marginparwidth=2.5cm, marginparsep=0.3cm]{geometry}
\usepackage{emptypage}		%para quitar los encabezados de las páginas en blanco
\usepackage[acronym,footnote]{glossaries}
\usepackage{hyperref}
\usepackage{epstopdf}

\usepackage{fancyhdr}		%paquete de encabezados
\pagestyle{fancy}

%%%%	TIPOGRAFIA	%%%%%%
\usepackage[default]{cantarell} %% Use option "defaultsans" to use cantarell as sans serif only
\usepackage[T1]{fontenc}

%contador Diseño
\newcounter{Disen}	
\newcounter{Disenii}[Disen]

\stepcounter{Disen}

%%%%% CHAPTERS STYLE %%%%%
\usepackage{fancyhdr}
\usepackage[Bjornstrup]{fncychap}

%%%%%%% ENCABEZADO %%%%%%
\usepackage{fancyhdr}		%paquete de encabezados
\pagestyle{fancy}
\fancyhead{}
\fancyfoot{}
\fancyhead[RO]{\nouppercase{\rightmark}}	%encabezado de pares: nombre de la sección
\fancyfoot[LE,RO]{\thepage}	%abajo a izqda en pares, derecha en impares: numero de pagina
\fancyhead[LE]{Diseño. Versión \theDisen.\theDisenii} %cuadro izquierdo de pagina par: parte y contador
\fancyhead[RE]{\nouppercase{\leftmark}}
\cfoot{ADVSM. Cauchy-team}
\renewcommand{\footrulewidth}{0.4pt}
\renewcommand{\headrulewidth}{0.4pt}		% linea por debajo del encabezado
\renewcommand{\sectionmark}[1]{\markright{\textbf{\thesection. #1}}}	%negrita

\input{glosario}

\raggedbottom
\begin{document}
\renewcommand{\chaptername}{Apartado}
\ \\
\vspace{3.5cm}

\thispagestyle{empty}



\begin{center}
\rule{12cm}{0.5pt}

\vspace{0.53cm}
\Huge{\textsf{Diseño}}

\rule{12cm}{0.5pt}
\end{center}

\begin{center}
\small{(Versión \theDisen.\theDisenii, \today)}\\
\end{center}

\vspace{1cm}

\begin{center}
\includegraphics[scale=0.78]{logo2.eps}

\vspace{0.3cm}

Proyecto para \textsc{Skirta, Sociedad Anónima}
\end{center}


\vspace{8cm}
\begin{minipage}{7cm}
\hspace{-1.9cm}\includegraphics[scale=0.43]{cauchyTeam.pdf}
\vspace{-1cm}
\end{minipage}

\tableofcontents

\listoffigures

\pagebreak
\raggedbottom

\input{DS_DSG_Diseño}

\input{DS_DIAM_Diagramas_diseño}


% los comentarios vienen marcados con un "%" al principio de línea
\chapter{Introducción}
En el presente documento desarrollaremos todo lo referente al análisis y diseño del producto software. Debido a la naturaleza del proyecto, sólo se
analizará y diseñará una pequeña parte (subsistema) del ADVSM, la referida a la gestión de la venta al cliente.

Para ello, se han tomado lo casos de uso y los requisitos de la especificación de requisitos software (\texttt{RQ\_SRS\_Requisitos})
y modelarlos para la creación de diferentes diagramas. Para la implementación se ha decidido usar Java, debido a la facilidad
para la gestión de elementos de índole gráfica (interfaces de usuario). 

%//Breve introducción sobre lo que se tratará en el documento. Se debe incluir, además, una visión
%general y poco detallada del sistema a desarrollar, decisiones o restricciones de diseño.
\section{Propósito}
Como dijimos ya en la especificación de requisitos software \texttt{nombre del documento aquí}, el propósito del
sistema softaware era suplir diferentes carencias detectadas en el mercado de programas de gestión de comercios 
minoristas. Uno de los puntos fuertes (y novedosos) de esta aplicación era la gestión de las áreas calientes del establecimiento.
Como ya se ha mencionado, las restricciones propias de la naturaleza del proyecto nos ha impedido implementar esta parte.

El sistema está enfocado a la gestión integral del proceso de venta de una cadena de tiendas monogram. Por ser  nuestro primer 
contrato con el cliente, de momento sólo se nos pidió la parte referida a la gestión de la venta, los clientes y la logística de las prendas.
Nuestro sistema opera, principalmente, en dos ambientes: la establecimiento en cuestión y las oficinas centrales de la compañía.

En la primera se gestiona las operaciones habituales de una tienda: entrada y salida de prendas, trato con el cliente, relaciones entre
el mánager del establecimiento y los empleados que en dicha tienda trabajan.
La segunda, en cambio, se encarga de la gestión general de la compañía: volumen de ventas, generación de estadísticas, administración de mercancía 
que llega directamente del proovedor, etcétera.

\section{Objetivos y restricciones de diseño}
Como nuestra aplicación opera en dos escenarios claramente diferenciados, hablamos de cada uno por separado.

\subsection{Establecimiento}
Los establecimientos se componen de terminales desde los cuales realizar las ventas, un servidor local (encargado de la gestión
del personal de la tienda, el inventario local y los clientes pertenecientes a esa tienda). Además, pueden existir otros ordenadores no
destinados a servir como TPV.

Todos estos elementos estarán conectados mediente una red LAN local y a través de internet con el servidor central.

\subsection{Oficinas centrales}
En el caso de las oficinas centrales, se tienen cantidades considerables de terminales dedicados a la gestión/administración de la compañía. El servidor
central también está ubicado aquí, al menos simbólicamente (pudiera ser que el sistema que gobierna el servidor
central fuese de tipo distribuido o algún otro tipo de sistema descentralizado).

Todos estos elementos están conectados mediante LAN e internet.

En todo caso, puede consultarse la sección 3 del documento de requisitos para más información sobre requisitos de seguridad, 
interfaces de usuario o calidad/fiabilidad del sistema.


%-Infraestructura tecnológica sobre la que el sistema opera. \\
%-Software con el que el sistema será construido.\\
%-Requisitos de interfaz de usuario que deberán imponerse al sistema.\\
%-Requisitos de seguridad, calidad y fiabilidad del sistema.\\
%-Estándares y normativas.\\

\section{Definiciones, acrónimos y abreviaturas}
Remitirse al documento de glosario \texttt{RQ\_GLO\_Glosario}.
\section{Referencias}
\begin{enumerate}
\item \textsc{Larman, C.}, \emph{UML y patrones}. Traducción de Begoña Moros.Madrid: Pearson Prentice Hall, 2003. ISBN 0-13-092569-1.
\item \textsc{Booch, G., Jacobson, I., Rumbaugh, J.}, \emph{El lenguaje unificado de modelado: manual de referencia}. Traducción de Salvador Sánchez. Madrid: Addison-Wesley, 2002. ISBN 84-7829-037-0. 
\end{enumerate}

\section{Estructura del documento}
En la sección que sigue a esta puede encontrarse la parte referida a requisitos. Para presentar el entoro en el cual la aplicación va a ejecutarse
se muestra primero el diagrama  de dominio.

Después se pasa a la parte de análisis. En primer lugar aparece el diagrama de paquetes de toda la aplicación. Luego se pasa directamente
a la modelización de los casos de uso que van a implementarse. Para ello se parte desde los diagramas de comunicación y a continuación se muestran 
los de clases. En todos los diagramas aparece una breve descripción de la secuencia de mensajes en el primer caso y de las clases involucradas en el segundo.

Respecto al diseño, optamos por mostrar los diagramas de secuencia y los diagramas de clases que corresponden a esta fase. Al igual que en la sección anterior, cada 
diagrama va acompañado de un breve comentario explicativo.

\chapter{Requisitos}
Como ya se dijo en la sección anterior, el diseño se centra en el módulo de ventas de la aplicación. El dominio que se presenta
pertenece al establecimiento.

\begin{center}
\begin{figure}[h!]
	\hspace{-2.7cm}\includegraphics[scale=0.85]{modeloDominio.pdf}
	\caption{Diagrama de modelo de dominio}
\end{figure}
\end{center}
Pueden verse en la figura las principales clases que intervienen en el proceso de venta minorista de nuestro cliente. 
En las asociaciones que se muestran se observa el papel predominante de las clases \texttt{Venta} y \texttt{Tienda},
pues son la parte principal del subsistema de ventas.

El diagrama es bastante ilustrativo acerca de las relaciones entre los distintos componentes que integran el proceso de venta. La única
relación que quizá merezca algún comentario es la de las clases  \texttt{AlmacénCentral} e \texttt{InventarioLocal}. 
La clase \texttt{AlmacénCentral}, en contra de lo que pudiera parecer, no es otro inventario más. Gestiona los inventarios de las tiendas, 
y también posee su propio inventario, pues se encarga de recibir las prendas del proveedor y distribuirlas a lo largo de los establecimientos.
Luego, de forma lógica, el \texttt{AlmacénCentral} es, además de un almacén en sí mismo, un gestor/contenedor de \texttt{InventarioLocal}.

\chapter{Análisis}
\section{Diagrama de paquetes}
Diagramas paquetes, comunicacion y clases del análisis. Diagramas de paquetes.
La figura \ref{diagramaPaquetes} (página \pageref{diagramaPaquetes}) muestra el diagrama de paquetes de la 
aplicación en su conjuto. Puede decirse los paquetes más externos representan subsistemas de la aplicación. Así, distinguimos cuatro grandes
módulos de ADVSM: el módulo de gestión de clientes (\texttt{ModuloClientes}), el módulo de seguridad (\texttt{Seguridad}), el módulo de gestión central
(\texttt{GestiónCentral}) y el módulo de tienda (\texttt{ModuloTienda}).

\begin{center}
\begin{figure}
	\label{diagramaPaquetes}
	\hspace{-1.5cm}\includegraphics[scale=0.8]{diagramaPaquetes.pdf}
	\caption{Diagrama de paquetes}
\end{figure}
\end{center}

\subsection{El \texttt{MóduloClientes}}
Encargado, como su nombre indica, de la gestión de los clientes. El módulo se encarga de dar altas y bajas de nuevos clientes, así como hacer consultas
sobre los mismos, o modificar sus datos.

El esterotipo \texttt{<<access>>} de este módulo hacia el paquete \texttt{Seguridad} viene dado por la necesidad de encriptación de datos de carácter personal
de los clientes, así como la necesidad de ciertos niveles de permiso para modificar datos sobre los clientes.

\subsection{El \texttt{MóduloTienda}}
El \texttt{MóduloTienda} representa todo aquello relacionado con el establecimiento que trata directamente con el cliente. Se divide en cuatro paquetes, a saber:
	\begin{description}
		\item[\texttt{ModuloVentas}] Modeliza el proceso de venta. Esta es la parte que se ha analizado y diseñado.
		\item[\texttt{InventarioTienda}] Representa el inventario local de una tienda. Contiene todos los procesos necesarios para su administración.
		\item[\texttt{ConsultasTienda}] Encargada de la parte de consultas respecto del volumen de ventas del establecimiento, gestión de clientes y empleados, etcétera.
		\item[\texttt{VisualTienda}] Es el responsable de la distribución fisica de los artículos dentro de la tienda, así como aquellos procesos relacionados con la optimización de 
			las ventas que con esta parte de la aplicación se pretende conseguir.
\end{description}

El estereotipo \texttt{<<import>>} de este paquete hacia el \texttt{MóduloClientes} representa la pertenencia
de los clientes a la tienda y lo que ello conlleva: libertad para crear, editar y eliminarlos. Además, como para cada cliente se registran sus compras,
se necesita acceso al cliente. Para mantener el nivel de seguridad y de acceso a datos personales de los clientes, se necesitan ciertos permisos, que vendrán dados
por el acceso al paquete de \texttt{Seguridad} (de ahí el estereotipo \texttt{<<access>>}).

\subsection{El paquete \texttt{GestiónCentral}}
Esta parte es la responsable de la gestión general de la empresa. Contiene los subpaquetes
\begin{description}
\item[\texttt{ModuloPersonal}] Encargado de la gestión del personal. Este módulo es muy básico, porque esta parte de la aplicación no entra dento 
del contrato con el cliente. Contiene la información necesaria para la gestión de accesos a la aplicacion.
\item[\texttt{AlmacénCentral}] Representa el almacén central y todas sus operaciones (recepción de prendas del proveedor, gestión de reposiciones,...).
\item[\texttt{ConsultasCentral}] De igual modo que \texttt{ConsultasTienda} se encargaba de generar estadísticas de ventas a nivel de tienda, éste paquete se encarga de 
eso mismo pero a nivel regional y nacional.
\end{description}


La dependencia bidireccional entre este paquete y el \texttt{ModuloTienda} estereotipado con \texttt{<<import>>} se justifica por la necesidad diaria
de actulización y sincronización entre las bases de datos central y local de las tiendas. Así mismo, desde las oficinas centrales se debe tener acceso y capacidad de
edición de clientes y empleados.

\subsection{El paquete \texttt{Seguridad}}
Encargado de las funciones que mantienen el nivel de seguridad dentro de la aplicación. Es el responsable de la administración
de permisos de los usuarios registrados en la aplicación y de sus niveles de acceso. Además, satisface las necesidades legales de protección de datos
personales mediante la encriptiación de los datos que contienen los servidores locales y central.


En cualquier caso, si se desea ampliar información, puede remitirse a la especificación de requisitos software (\texttt{RQ\_SRS\_Requisitos}), seccion 3 \emph{Requisitos específicos}.
\section{Diagramas de comunicación}
\paragraph{Pago en efectivo}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.6]{Diagramas/Analisis/Comunicacion/pagoefectivo.pdf}
	\caption{Diagrama de comunicación de \emph{Pago en efectivo}}
\end{figure}
La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a un pago en efectivo. Éste crea una venta, y se comunica con \texttt{PagoEfectivo}, tramitando el pago de cierto importe. \texttt{PagoEfectivo} efectúa el pago, comunicándose con las entidades \texttt{Caja} y \texttt{Venta}, y devuelve a \texttt{Venta} información acerca de si se ha realizado correctamente. Por último se redirige esta información a la interfaz \texttt{MainWindow}.
	
\paragraph{Pago con vale}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.6]{Diagramas/Analisis/Comunicacion/pagovale.pdf}
	\caption{Diagrama de comunicación de \emph{Pago con vale}}
\end{figure}
	La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a un pago con vale. Éste crea una venta, y se comunica con \texttt{PagoEfectivo}, tramitando un pago con importe 0. \texttt{PagoEfectivo} efectúa el pago, comunicándose con las entidades \texttt{Venta}, \texttt{Caja} y \texttt{Vale}, y devuelve a \texttt{Venta} información acerca de si se ha realizado correctamente. Por último se redirige esta información a la interfaz \texttt{MainWindow}.
	
\paragraph{Pago con tarjeta}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Comunicacion/pagotarjeta.pdf}
	\caption{Diagrama de comunicación de \emph{Pago con tarjeta}}
\end{figure}
	La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a un pago con tarjeta. Éste crea una venta, y se comunica con \texttt{PagoTarjeta}, tramitando el pago de cierto importe. \texttt{PagoTarjeta} efectúa el pago, comunicándose con las entidades \texttt{Caja},\texttt{Venta}  y \texttt{Tarjeta}, y devuelve a \texttt{Venta} información acerca de si se ha realizado correctamente. Por último se redirige esta información a la interfaz \texttt{MainWindow}.
	
\paragraph{Devolución}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Comunicacion/devolucion.pdf}
	\caption{Diagrama de comunicación de \emph{Devolución}}
\end{figure}
	La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a una devolución. Éste crea una venta, y se comunica con \texttt{Pago}, tramitando la devolución de cierto importe. Dicha comunicación devuelve a la venta información acerca de si se ha realizado correctamente la devolución. Si es así, \texttt{Venta} se comunica con \texttt{Vale} de forma que se genera un vale, y se informa a la venta de si se ha generado correctamente, y ésta comunica la misma información de vuelta a la interfaz \texttt{MainWindow}.

\paragraph{Venta}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Comunicacion/venta.pdf}
	\caption{Diagrama de comunicación de \emph{Venta}}
\end{figure}
	La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a una venta. Éste crea una venta, por lo que se comunica con la entidad \texttt{Venta}. Si se produce un error creando la venta, se notifica a la inrefaz \texttt{MainWindow}. Si no, se produce a realizar el pago, bien sea comunicando con \texttt{PagoTarjeta}, o bien con \texttt{PagoEfectivo}.
	
\paragraph{Imprimir factura}
	\begin{figure}[h!]
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Comunicacion/imprimirfactura.pdf}
	\caption{Diagrama de comunicación de \emph{Imprimir factura}}
\end{figure}
	La interfaz \texttt{MainWindow} informa al controlador de que se va a proceder a hacer una factura. Éste busca la venta, por lo que se comunica con la entidad \texttt{Venta}. Una vez encontrada la venta, se genera la factura, y para ello debe comunicar con la entidad \texttt{Factura}. Ya generada la factura, se vuelve a la interfaz \texttt{MainWindow}, para mostrar la factura generada. 
	
\section{Diagramas de clases}
Para estos diagramas de clases nos limitamos a mostrarlos. Las relaciones son explicadas en el propio diagrama.
\begin{figure}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Clases/pagovale.pdf}
	\caption{Diagrama de clases (análsis) de \emph{Pago en efectivo}}
\end{figure}
En el caso de \emph{pago con vale}, las clases intervinientes son las mismas. La única diferencia con un pago en efectivo corriente es que el pago con vale puede llegar a tener un importe de 0 euros (si 
se poseen los vales válidos suficientes).
\begin{figure}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Clases/pagotarjeta.pdf}
	\caption{Diagrama de clases (análsis) de \emph{Pago con tarjeta}}
\end{figure}

\begin{figure}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Clases/devolucion.pdf}
	\caption{Diagrama de clases (análsis) de \emph{Devolución}}
\end{figure}
\begin{figure}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Clases/venta.pdf}
	\caption{Diagrama de clases (análsis) de \emph{Venta}}
\end{figure}
\begin{figure}
	\centering
	\includegraphics[scale=0.7]{Diagramas/Analisis/Clases/imprimirfactura.pdf}
	\caption{Diagrama de clases (análsis) de \emph{Imprimir factura}}
\end{figure}

\chapter{Diseño}
En esta sección abordaremos todo aquello relacionado con la implementación y el diseño propiamente dichos. Antes de pasar a los diagramas
de diseño, procedemos a exponer de forma breve los patrones usados para la implementación, para que sirvan de guía en esta sección.
\section{Patrones}
\begin{itemize}
	\item{\textbf{Experto:}}
		La venta conoce el total de la misma, y a su vez cada producto conoce su precio individual. 
		La misma situación ocurre con los descuentos de los vales.
	\item{\textbf{Creador} y \textbf{Bajo acoplamiento:}}
		El controlador crea la venta para agregarla a la base de datos, ya que tiene todos los datos necesarios para hacerlo, 
		sin embargo, no crea el pago para evitar un alto acoplamiento, función que delega en la venta en sí, 
		consiguiendo un patrón de bajo acoplamiento.
	\item{\textbf{Alta cohesión, indirección} y \textbf{\emph{don't talk to strangers}:}}
		A la hora de actualizar el visual, se realiza una petición al controlador para que indique a la 
		base de datos que necesita enviar un evento a la vista, consiguiendo una cadena cohesiva de llamadas entre objetos.
	\item{\textbf{Controlador:}}
		La clase \texttt{ControladorVentas} atiende los eventos generados por el usuario, que pasa a quién 
		sea necesario, sin que las clases de la interfaz sepan el funcionamiento interno.
	\item{\textbf{Polimorfismo:}}
		Las clases de pago son polimórficas de manera que la venta en ningún momento conoce qué tipo
		de pago se ha utilizado en ella, sino que sólo tiene acceso a una serie de métodos especificados en la interfaz de pago.
	\item{\textbf{\emph{Factory method:}}}
		La venta no es quién crea el pago, sino que es él mismo el que decide qué tipo de pago deberá 
		crear mediante un método estático de la clase.
	\item{\textbf{\emph{Singleton:}}}
		La base de datos cuenta con una única instancia en todo momento a la que sólamente se puede 
		acceder desde un método estático como punto único de entrada en la aplicación.
	\item{\textbf{\emph{Composite:}}}
		La parte visual, aunque implementada con librerías externas, trabaja mediante este patrón para 
		crear ventanas más complejas componiendo una serie de elementos más básicos.
	\item{\textbf{Decorador:}}
		De nuevo en la parte visual, la manera de agregar por ejemplo las barras de scroll es 
		mediante un decorador que las añade al componente interno.
	\item{\textbf{\emph{Façade:}}}
		Los objetos que llegan a la vista son todos interfaces que, si bien ocultan objetos
		modificables, sólo permiten el acceso a los métodos observadores de éstos, evitando 
		así que la vista modifique directamente el modelo.
	\item{\textbf{\emph{Observer:}}}
		La manera de enterarse la vista de lo que ocurre en el modelo es mediante un observador. 
		El modelo cuenta con una lista de observadores que actualiza ante cualquier cambio en la representación 
		interna, sin necesidad de saber a quién está actualizando.
\end{itemize}

A continuación, los diagramas de secuencia y clases de los casos de uso implementados.
\section{Diagramas de secuencia}
\paragraph{Pago en efectivo}
\begin{figure}
	\centering
	\includegraphics[scale=0.72]{Diagramas/Diseno/Secuencia/pagoefectivo.pdf}
	\caption{Diagrama de secuencia de \emph{Pago en efectivo}}
\end{figure}
	La ventana principal solicita con \texttt{createAndAddVenta()} al controlador de ventas que cree una venta, y que éste la añada con \texttt{addVentas()} al array de ventas . Desde aquí se llama a \texttt{realizaVenta()}, desde donde se tramita el pago con \texttt{parsePagoCompleto()}, y se efectúa llamando al método \texttt{efectuar()} de la clase Venta. Se devuelve un booleano \texttt{ventaRealizada} como retorno de \texttt{realizaVenta()}, y se registra el cambio en el inventario. Pueden producirse errores creando o añadiendo ventas, en cuyo caso se controlan las excepciones lanzadas.
	
\paragraph{Pago con vale}
\begin{figure}
	\centering
	\includegraphics[scale=0.72]{Diagramas/Diseno/Secuencia/pagovale.pdf}
	\caption{Diagrama de secuencia de \emph{Pago con vale}}
\end{figure}
	La ventana principal solicita con \texttt{createAndAddVenta()} al controlador de ventas que cree una venta, y que éste la añada con \texttt{addVentas()} al array de ventas . Desde aquí se llama a \texttt{realizaVenta()}, desde donde se tramita el pago, como si fuera un pago normal con importe 0, con \texttt{parsePagoCompleto()}, y se efectúa llamando al método efectuar() de la clase Venta. Se devuelve un booleano \texttt{ventaRealizada} como retorno de \texttt{realizaVenta()}, y se registra el cambio en el inventario. Pueden producirse errores creando o añadiendo ventas, en cuyo caso se controlan las excepciones lanzadas.

\paragraph{Pago con tarjeta}
\begin{figure}
	\centering
	\includegraphics[scale=0.72]{Diagramas/Diseno/Secuencia/pagotarjeta.pdf}
	\caption{Diagrama de secuencia de \emph{Pago con tarjeta}}
\end{figure}
	La ventana principal solicita con \texttt{createAndAddVenta()} al controlador de ventas que cree una venta, y que éste la añada con \texttt{addVentas()} al array de ventas. Se construye la venta con el constructor \texttt{Venta}. Si la información de pago que se le pasa a la venta es válida, se tramita el pago con tarjeta, llamando a \texttt{parsePago()}, y luego a \texttt{PagoTarjeta()}. Si no, \texttt{parsePago()} falla, devolviendo null y entonces no se realiza el pago. Si el pago se ha completado correctamente, se añade la venta al array de ventas con \texttt{add()}, y se cambia el inventario con \texttt{onInventoryChange()}.
	
\paragraph{Devolución}
\begin{figure}
	\centering
	\includegraphics[scale=0.72]{Diagramas/Diseno/Secuencia/devolucion.pdf}
	\caption{Diagrama de secuencia de \emph{Devolución}}
\end{figure}
	La ventana principal se comunica con el controlador de ventas con el método \texttt{descuenta()} que indica el inicio del proceso de devolución. Desde el controlador de ventas se descuenta cierto importe con los métodos \texttt{descuenta()} del controlador al array de ventas, y \texttt{descontar()}, de dicho array a la venta. Después de esto se procesa la devolución, se llama al método \texttt{devuelve()}, y si la devolución se hace correctamente, se genera un vale de descuento. Y si no, devuelve \texttt{null}, y no se procesa la devolución.
	 
\paragraph{Venta}
\begin{figure}
	\hspace{-0.7cm}\includegraphics[scale=0.72]{Diagramas/Diseno/Secuencia/venta.pdf}
	\caption{Diagrama de secuencia de \emph{Venta}}
\end{figure}
	La ventana principal solicita con \texttt{createAndAddVenta()} al controlador de ventas que cree una venta, y que éste la añada con \texttt{addVentas()} al array de ventas. Se crea la venta, verificando primero el parámetro referido al cliente (si no es válido, devuelve null y no se procede a la venta), después el empleado (igual que el caso anterior), y por último los datos del pago (lo mismo, si los datos son correctos, se tramita el pago. Si no, se devuelve null y la venta falla).

\paragraph{Imprimir factura}
\begin{figure}
	\centering
	\includegraphics[scale=0.78]{Diagramas/Diseno/Secuencia/imprimirfactura.pdf}
	\caption{Diagrama de secuencia de \emph{Imprimir factura}}
\end{figure}
	La ventana principal se comunica con el controlador de ventas con el método \texttt{factura()}, que indica el inicio del proceso.  Desde el controlador de ventas se llama al método \texttt{factura()}, que accede al array de ventas, y con su propio método \texttt{factura()}, obtiene la venta primero con \texttt{getVenta()}, y luego hace la factura llamando a \texttt{generarFactura()}, para lo que también se tiene que llamar, obviamente, al constructor \texttt{Factura()}.
	
\section{Diagramas de clases}
\paragraph{Pago en efectivo}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/pagoefectivo.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Pago en efectivo}}
\end{figure}
	La clase \texttt{PagoEfectivo} hereda de la clase \texttt{Pago}, pues hace uso de algunos métodos específicos para tramitar un pago en efectivo. Esta clase \texttt{Venta} tiene un atributo de la clase \texttt{Pago}, que servirá para procesar la venta, o también para procesar las devoluciones y facturas.
	
\paragraph{Pago con vale}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/pagovale.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Pago con vale}}
\end{figure}
	La clase \texttt{PagoEfectivo} hereda de la clase \texttt{Pago}, pues hace uso de algunos métodos específicos para tramitar un pago en efectivo, aunque este sea un pago con vale (se realiza un pago en efectivo con importe nulo). Esta clase \texttt{Venta} tiene un atributo de la clase \texttt{Pago}, que servirá para procesar la venta, o también para procesar las devoluciones y facturas. También tiene un arrayList de vales usados, que servirá para llevar la cuenta de los vales de descuento que se acumulan en la venta, para procesar ésta correctamente.
	
\paragraph{Pago con tarjeta}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/pagotarjeta.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Pago con tarjeta}}
\end{figure}
	La clase \texttt{PagoTarjeta} hereda de la clase \texttt{Pago}, pues hace uso de algunos métodos específicos para tramitar un pago con tarjeta. Esta clase \texttt{Venta} tiene un atributo de la clase \texttt{Pago}, que servirá para procesar la venta. 
	
\paragraph{Devolución}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/devolucion.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Devolución}}
\end{figure}
	La clase \texttt{MainWindow} tiene un atributo de la clase \texttt{ControladorVentas}, al que acudirá cuando quiera empezar a procesar una devolución. Este controlador contiene un atributo de la clase \texttt{VentaArray} (donde almacena las ventas), que a su vez tiene dos arrayList de objetos de la clase \texttt{Venta}. Este objeto posee un arrayList de objetos de la clase \texttt{Vale}, y un atributo de la clase \texttt{Pago}.
	
\paragraph{Venta}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/venta.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Venta}}
\end{figure}
	La clase \texttt{MainWindow} tiene un atributo de la clase \texttt{ControladorVentas}, al que acudirá cuando quiera empezar a procesar una venta.Este controlador contiene un atributo de la clase \texttt{VentaArray} (éste hereda de la clase \texttt{Observable<VentaArrayObserver>}), que tiene un arrayList de objetos de clase \texttt{Venta}. Esta clase \texttt{Venta} implementa la interfaz \texttt{VentaInterface}. Además, tiene como atributos: un objeto de la clase \texttt{Empleado}, referente al empleado que realiza la venta; un arrayList de objetos de tipo \texttt{Prenda}, que almacena las prendas incluidas en la venta; un objeto de tipo \texttt{Cliente}, que será el comprador; y por último un arrayList de objetos de clase \texttt{Vale}, que representa los vales de descuento usados en la venta. La clase \texttt{Vale} implementa la interfaz \texttt{ValeInterface} 

\paragraph{Imprimir factura}
\begin{figure}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Diseno/Clases/imprimirfactura.pdf}
	\caption{Diagrama de clases (diseño) de \emph{Imprimir factura}}
\end{figure}
	La clase \texttt{MainWindow} tiene un atributo de la clase \texttt{ModeloTablaVentas}, el cual hereda de \texttt{RowTableModel<T>}. Éste se usará para que implementar correctamente la tabla de ventas. Además, \texttt{MainWindow} también tiene un atributo de la clase \texttt{ControladorVentas}, que se usa para acceder a la información de la venta, obteniendo ésta a partir de la información de la tabla de ventas, y a través de un atributo que tiene de la clase \texttt{VentaArray}, donde están almacenados los objetos de la clase \texttt{Venta}. Después de explicar estas relaciones, sólo queda aclarar que la clase \texttt{Factura} está, por supuesto, en una dependencia directa de la clase \texttt{Venta}, pues no se puede hacer una factura de una venta que no se ha producido.
\section{Diagramas de componentes}
La figura 4.13muestra el diagrama de componentes. En este diagrama aparecen los componentes (ya sean objetos externos como subsistemas propios)
necesarios para la parte implementada, la venta.

La ventana principal \texttt{MainWindow} depende del sistema de login, sin el cual no puede utilizarse la aplicación. Dentro del propio módulo, las \texttt{Ventas} comunican
con dicha ventana principal a través de la interfaz \texttt{VentaInterface}. Lo mismo ocurre entre las \texttt{Venta} y \texttt{Factura}, \texttt{Pagos}, que a través de la interfaz \texttt{Venta} consiguen
comunicarse. A su vez, tanto el cajón de la caja registradora como la entidad bancaria depende de \texttt{Pago} (según sea el tipo de pago, efectivo o tarjeta).

Por último, un servicio de impresión, aquí descrito como \texttt{Impresora} presenta una dependencia respecto de \texttt{Facturas}, por las razones obvias.
\begin{figure}
	\label{fig:componentes}
	\centering
	\includegraphics[scale=0.75]{Diagramas/Componentes/componentes.pdf}
	\caption{Diagrama de componentes}
\end{figure}

\section{Diagramas de despliegue}
La figura 4.14 muestra el diagrama de despliegue de la parte implementada, la venta. Pueden verse tres tipos de nodos. Los detallamos a continuación
\begin{description}
\item{\textbf{:Terminal}} Reprenta un TPV del estableciemieto. En el puede verse dentro un nuevo nodo, \textbf{:ADVSM\_local}, que reprenseta la versión local de ADVSM instalada en el terminal físico (nótese que aparece un ejecutable de nombre \emph{ADVSM\_tiendas.jar}
Puede apreciarse también el sistema de login para los empleados del local (el LDAP local; véase \texttt{RQ\_SRS\_Requisitos} y \texttt{RQ\_DCU\_Casos\_uso}). Así mismo, queda patente la dependencia del sistema ADVSM con las librerías locales de Java, que deben estar presenta 
en el terminal.
\item{\textbf{:Servidor\_local}} El servidor local del establecimiento. En su interior se ve una ejecución de ADVSM\_ServidorLocal, que no es más que una forma de representar los subsistemas encargados de gestionar las
ventas del local, así como su inventario, sus clientes y sus empleados. Lo que aparentemente es una asociación bidireccional, en realidad es una dependencia bidireccional (fallo de renderizado gráfico). La dependencia entre los cuatro subsistemas que trabajan dentro del servidor 
queda justificada por la naturaleza de nuestro producto software: a los empleados se les anotan las ventas que realizan, y obviamente la ventas dependen de clientes y artículos de inventario. También aparece la conexión de este servidor con los terminales de su domino,
mediante red LAN.
\item{\textbf{centralServer:ServidorCentral}} El único servidor central de la compañía, de ahí que tenga nombre. Contine los subsistemas correspondientes a la gestión general de empleados, clientes e inventario, así como la gestión de las credenciales. La conexión TCP/IP con los servidores
locales se justifica por la sincronización diaria de los datos guardados en los servidores de los estableciemientos y el servidor central (véase \texttt{RQ\_SRS\_Requisitos}, sección 3.1).

\end{description}

\begin{figure}
	\label{fig:despliegue}
	\centering
	\includegraphics[scale=0.70]{Diagramas/Despliegue/despliegue.pdf}
	\caption{Diagrama de despliegue}
\end{figure}

\end{document}